(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 




(19) World Intellectual Property Organization 

International Bureau 

(43) International Publication Date (10) International Publication Number 

29 November 2001 (29.11.2001) PCT WO 01/91382 Al 



(51) International Patent Classification 7 : 

H04Q 7/22 



H04L 12/56, 



(21) International Application Number: PCT/EP00/04647 



(22) International Filing Date: 22 May 2000 (22.05.2000) 



(25) Filing Language: 



(26) Publication Language: 



English 



English 



(71) Applicant (for all designated States except US): NOKIA 
NETWORKS OY [FI/FI]; Keilalahdenlie 4, FIN-02150 

Espoo (FI). 

(72) Inventors; and 

(75) Inventors/Applicants (for US only): HURTTA, Tuija 

[FI/FI]; Kiskottajankuja 4 D 49, FIN-02660 Espoo (FT). 
HAUMONT, Serge [FI/FI]; Riistavuorenkuja 3 B 10, 
FIN-00320 Helsinki (FI). 



(81) Designated States (national): AE, AG, AL, AM, AT, AU, 

AZ, BA, BB, BG, BR, BY, CA, CH, CN, CR, CU, CZ, DE, 
DK, DM, DZ, EE, ES, FI, GB, GD, GE, GH, GM, HR, HU, 
ID, IL, IN, IS, JP, KE, KG, KP, KR, KZ, LC, LK, LR, LS, 
LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, MZ, NO, 
NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, SL, TJ, TM, TR, 
TT, TZ, UA, UG, US, UZ, VN, YU, ZA, ZW. 

(84) Designated States (regional): AR1PO patent (GH, GM, 
KE, LS, MW, MZ, SD, SL, SZ, TZ, UG, ZW), Eurasian 
patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), European 
patent (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, 
IT, LU, MC, NL, PT, SE), OAPI patent (BF, BJ, CF, CG, 
CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG). 

Published: 

with international search report 

For two-letter codes and other abbreviations, refer to the "Guid- 
ance Notes on Codes and Abbreviations " appearing at the begin- 
ning of each regular issue of the PCT Gazelle. 



(74) Agents: LESON, Thomas, Johannes, Alois ct al.; 
Tiedtke-Buhling-Kinne. Bavariaring 4, D-80336 Munich 

(DE). 



(54) Title: SYSTEM AND METHOD FOR PROVIDING A CONNECTION IN A COMMUNICATION NETWORK 



RNC 



J. CONNECTS 

□ cr ici-T •" 



£ REQUEST FOR L'ST OF 



DNS 
SERVER 



SGSN 



SGSNs iRAl) 
3. RESPONSE 



RECUEST 
RESPONSE 



00 

£2 (57) Abstract: The invention proposes a system and method for providing a connection in a communication network which coiti- 
on prises several network elements and is adapted to route a connection via a first network element such as a radio network controller and 
one or more of alternatively selectable second network elements such as serving nodes. The network comprises a network element 
which stores a list of selectable second network elements. The list is accessed using an identifier identifying a routing or location 
area or a desired second network element. The list can be stored in a DNS server which returns to an inquiring network element 
Q such as a radio network controller, e.g. IP addresses of serving nodes capable of serving a routing or location area of a connection 
originating or terminating network clement. The connection originating or terminating network clement may also be adapted to send 
^ an identifier identifying a specific network element such as an SGSN to which it desires to be connected. 
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SYSTEM AND METHOD FOR PROVIDING A CONNECTION 
IN A COMMUNICATION NETWORK 

FIELD OF THE INVENTION 

The present invention relates to a system and method for 
10 providing a connection in a communication network. The 

communication network may be a pure data network, a network for 
transmitting data and/or other type of information such as 
speech or may be a network exclusively reserved for non-data 
information. The network can be a circuit-switched network, a 
15 packet-switched network such as a GPRS or UMTS network, or may 
consist of a combination of networks of different type. 

BACKGROUND OF THE INVENTION 

20 

When providing a connection in a communication network, usually 
several network elements are involved, including the connection 
originating network element, the connection terminating network 
element and/or one or more intermediate network elements such 
25 as a base station, a base transceiver station, a base station 
controller and/or one or more support nodes handling the 
signalling and/or user traffic. 

As an example, in a GPRS-based or UMTS-based network, a 
30 connection (e.g. call) originating from, or terminating at, a 
user equipment such as a mobile station (MS) is made to a 
connection terminating or originating equipment using a radio 
network controller (RNC) which communicates with a SGSN 
(Serving GPRS Support Node) and possibly a GGSN (Gateway GPRS 
Ab Support Node) . The connection terminating or originating 

equipment can be located in the same or a different network. In 
particular, in case of mobile user equipments, the actual 
location thereof is defined with a resolution of a routing area 
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(e.g. in idle state) or with a finer -resolution of a cell (e.g. 
when handling a connection such as a call) . Note that Routing 
area (RA) is a standard term used in conjunction with GPRS, 
while GSM and UMTS Circuit Switched systems use the term 
Location Area (LA) . In both case, the area is referring to the 
area where a mobile station is registered in the serving node 
(e.g SGSN or MSC/VLR) , and where eventually the serving node 
pages the mobile station to establish downlink connection. In 
this application, the term area will be used to refer to 
location area and/or routing area. 

The coverage area of an entire network is usually divided in 
several areas (RA or LA), with one area (in a GPRS-or UMTS- 
based network) being assigned to one serving node (one serving 
node typically handling many areas) . When having information on 
the area where the user equipment is presently located, the 
serving node in charge of handling a connection to or from this 
user equipment is unambiguously defined. 

For example, in GSM and UMTS, this one to one correlation 
between the routing or location areas and the assigned SGSNs 
may, however, be of disadvantage in case of break-down of an 
SGSN or necessary maintenance operations such as software 
updating. In such a case, the routing area has to be completely 
shut-down and is at least temporarily no longer usable for 
providing connections. 

This situation may be significantly improved when changing the 
network structure in such a manner that at least two serving 
nodes such as two SGSNs are able to handle the same routing 
area. In such a case, e.g. a base station controller (BSC) or 
radio network controller (RNC) may use different interfaces 
such as Iu and/or Gb. Several types of mobile stations may be 
supported by using two radio interfaces and providing only one 
single base transceiver station (BTS) . 
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The provision of two or more support nodes serving the same 
routing area provides several advantages such as resilience by 
enabling an RNC (possibly having a list of available SGSNs) to 
use another SGSN if the previously used SGSN should become 
overloaded or out of order. Furthermore, maintenance operations 
such as software updates can be effected without shutting down 
the area. In addition, the network signalling caused by inter- 
SGSN hand-over can be reduced. 

As an example, several SGSNs may be provided for covering a 
metropolitan area such as London area, and a mobile station 
moving around the city can always use its original SGSN for 
handling connections. 

For instance, an IP network may be introduced on an interface 
such as Iu interface which presently is mainly used as a point- 
to-point Iu interface between the RNC and the SGSN. When 
introducing an IP network or network of some other appropriate 
type on the Iu interface, one RNC may be connected to several 
SGSNs. 

In a case where one network element (which e.g. is in charge of 
controlling the radio connection to a user equipment) is able 
to connect to different support nodes being alternatively 
provided, there exists a problem in finding and selecting an 
appropriate support node, for instance an SGSN to be used for a 
signalling connection. This signalling connection may e.g. be 
used to transfer L3 (layer 3) messages (such as mobility 
management MM and session management SM) between the user 
equipment (e.g. MS) and the support nodes such as SGSN. 
Furthermore, in case of inter-support node hand-over the new 
support node would benefit from finding the old support node 
which was serving the user equipment until hand-over. 

SUMMARY OF THE INVENTION 
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The present invention provides a solution for solving or at 
least relieving the above problems either partly or entirely. 

According to one aspect, the invention provides a system as 
defined in claim 1. This system may consist of a whole network, 
may be only a part of a network, or may comprise two or more 
networks . 

According to a further aspect, the invention provides a method 
as defined in the independent method claim. 

The invention additionally provides, according to a further 
aspect, one or more network elements equipped so as to 
implement the hardware structure or functions usable in a 
network or connection or selection method as defined in the 
claims and/or described in the present specification. 

The present invention provides a solution for allowing a first 
network element such as a radio network controller or base 
station controller to decide which support node (e.g. SGSN) to 
use for a connection (e.g. signalling connection or user 
traffic connection) . A signalling connection is provided for 
transferring messages such as L3 messages, e.g. MM and SM, 
between a network element such as a user equipment, e.g. MS, 
and the support node. Hence, the first network element may be 
alternatively connected to different support nodes serving e.g. 
the same routing area. Such an implementation provides the 
advantages mentioned above. 

The invention is also providing, in case of hand-over of a 
connection between different support nodes such as SGSNs, a 
structure and method enabling the new support node to find the 
old support node serving the user equipment up to now. 
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In accordance with the invention, an area identifier such as 
"Routing Area Identity ( RAI ) " may be used by the first network 
element (e.g. RNC) to derive a list of alternatively selectable 
second network elements such as support nodes. In this list 
different support node are identified by their addresses. This 
list may be preconf igured inside the RNC. According to another 
embodiment, the first network element may send a message or 
request containing the identifier (e.g. RAI) to another network 
element such as a DNS (Domain Name System) server in order to 
receive, as a response, a list of possible second network 
elements serving the routing area indicated by the RAI. This 
avoids the need of preconf igured list, and DNS is particularly 
suitable if the list of possible second network elements 
contains IP addresses. 

The another network element preferably contains, or co-operates 
with, a memory storing the list (table) of possible second 
network elements, and may send this list as a rolling or 
distributed list to spread the load. The list may for instance 
be sent in form of several parts, each part indicating only one 
or two (or more) selectable second network elements. The list 
may be ranked in a defined order, for instance based on the 
address of the first network element sending the list request 
or indicating first a default second network element for this 
area. The ranking may be such that the first of the second 
network elements indicated in the list is always the closest 
one to the first network element, the second of the listed 
second network elements being the second closest one to the 
first network element, etc. 

The order of listing of the second network elements in the list 
may also, in an embodiment, be based on information on the 
actual or previous load of each listed second network element. 
As an alternative, the order of listing of the second network 
elements may be kept unchanged, but additional information is 
attached to the list indicating the actual or previous load 
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condition of the listed second network elements. In the latter 
case, the first network element is adapted to check the load 
condition information as well, and to select one of the second 
network elements having the smallest load or at least being one 
of the lighter-loaded second network elements. 

The modification of the order of the listing of the second 
network elements taking account of the load, or the attachment 
of the load information to the list, is preferably performed by 
the operation and maintenance system (O&M) provided for the 
network. 

According to one possible implementation of the invention, a 
second network element for which a maintenance operation such 
as software updating is planned, may be withdrawn from the list 
(to be sent to an inquiring first network element) some time 
such as a few hours before the software update. In such a way, 
one can ensure that no or at least not many connections or 
contexts will still be handled by this second network element. 

According to one possible implementation of the invention, if a 
second network element is not responding, another second 
network element may be selected from the list 

According to one possible implementation, the identifier such 
as CN (Core Network) Identifier may be added to a message, 
e.g. RRC (Radio Resource Control) message which is used to 
initiate a connection and/or carry a message such as a L3 
message (e.g. Attached Request, Routing Area Update Request or 
Service Request). The first network element (e.g. RNC) checks 
the identifier (e.g. CN Identifier ) from the RRC message 
message. In addition, the first network element may also be 
adapted to deduce the area identifier such as RAI from the cell 
where the user equipment is actually located. The combination 
of area identifier and CN Identifier identifies unambiguously 
the serving node. The first network'.:element derives the serving 
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node address from a list. In one embodiment, the first network 
element uses the area identifier and/or the CN identifier to 
request the list-transmitting network element such as a DNS 
server to send a list of second network elements assigned to 
the transmitted identifier. 

Certain systems, such as GSM or UMTS systems have different 
types of serving nodes (e.g. SGSN and MSC/VLR) serving the same 
area. In the UMTS system, the RRC signalling contains a 
parameter (CN domain identity) identifying the CN type. In GSM, 
the CN type is identified implicitely from the type of channel 
established. 

In such systems, the indication of CN type in addition to the 
combination of area identifier and CN Identifier may be needed 
to identify unambiguously the serving node. 

According to one possible implementation of the invention, one 
of the second network elements may be set as a default second 
network element serving the routing area in which the 
connection terminating or originating equipment such as MS is 
presently located. The first network element will be configured 
to use this default second network element for handling a 
connection as long as no other second network element is 
selected (i.e CN identifier is not sent by the MS). 

In accordance with an embodiment of the invention, the 
selection of one of the available second network elements 
covering a certain routing area may be performed in dependence 
on information coming from other network element such as a user 
equipment, for instance a mobile station. If the user equipment 
wants to establish a connection, e.g. a signalling connection, 
to a certain support node (second network element) which for 
instance had previously handled the connection to and from this 
user equipment, the user equipment is preferably adapted to 
send additional information such as CN identifier to e.g. the 
first network element which may be a RNC. As an example, the 
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user equipment had established a signalling connection to a 
certain support node, e.g. SGSN, whereafter the signalling 
connection had been released, and the user equipment wants to 
establish the signalling connection again to the same support 
node . 

In accordance with one aspect of the invention, the user 
equipment may then add an identifier information such as CN 
identifier to a message which, e.g., may be used to carry an L3 
message (e.g. a Routing Area Update Request or Service 
Request) . If the MS moves to a new area which cannot be handled 
by the previous serving node in which it is registered, RNC 
will select a new serving node, and the new serving node will 
be able to derive the old serving node address by using the 
combination of CN identifier (added according to this 
embodiment to Routing Area Update Request) and old RAI (sent in 
Routing Area Update Request in GSM and UMTS) . In addition, or 
as an alternative, the first network element (e.g. RNC) may 
check the information CN identifier from the L3 message. 

The new serving node should send its CN identifier in e.g. 
Routing Area Update accept, or attach accept to the MS. 

The invention furthermore provides a possibility of finding and 
selecting an old support node (e.g. old SGSN) by a new support 
node, in particular after inter-node hand-over. Note that in a 
structure in which the old SGSN can be found with the old RAI 
(when only one SGSN serves a specific routing area designated 
by RAI), there is no problem in finding the old SGSN. However, 
in a situation where a routing area is covered by several 
support nodes in parallel, it will be advantageous if the new 
support node is able to detect the old support node in order to 
e.g. copy context information for handling the connection such 
as PDP (Packet Data Protocol) context information. 
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According to one aspect of the invention', the network element 
storing the list of second network elements (i.e. support 
nodes) covering a certain area such as RA (Routing Area) or LA 
(Location Area) may additionally store, for each support node, 
an CN identifier identifying this support node. This identifier 
may be sent as a new Information Element (i.e. it is sent 
explicitely) or may be coded as part of another Information 
Element such as a temporary identity (i.e. it is sent 
implicitely) . As an example of sending the CN identifier 
implicitely, CN identifier may be formed by some bits (e.g. 4 
last bits) of PTMSI (Packet Temporary Mobile Station Identity) . 
The network element storing the list of second network elements 
available for the respective areas (e.g. RA or LA) can be a DNS 
server, and preferably stores the list of support nodes mapped 
to the respective area indicators such as RAIs (Routing Area 
Identities) or LAIs (Location Area Identities) . This network 
element may return, in response to an area indicator sent to 
it, not only the IP addresses of every support node (second 
network element) assigned to the respective area (e.g. RAI), 
but additionally also the network element identifiers assigned 
to these support nodes, and eventually the type of support 
node. The network element in charge of selecting the second 
network element for handling the connection (e.g. signalling 
connection) may then select that second network element which 
has an network element identifier corresponding to the network 
element identifier transmitted e.g. from the user equipment as 
selection criterion. As an alternative, the network element 
storing the list may be queried with both CN identifier and 
area identifier, so that only the address of the right support 
node is returned. 

The type of support node may be used e.g.' in a network 
comporting both 2G and 3G SGSN. In this case, a RNC (3G only) 
may only select a support node indicated as a 3G support node, 
based on the type of support node indicated. 
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In order to avoid processing problems, according to one aspect 
of the invention, one of the second network elements (e.g. 
SGSN) available for a routing area may be a master network 
element which, if not handling itself the context information 
such as PDP context, may act as a relay, and may determine the 
old second network element based on e.g. the identifier sent 
for instance from the user equipment together with PTMSI. In 
such a case, the identifier may have been sent from the old 
support node to the user equipment together with PTMSI during 
(e.g. at the begin or end) of the time period during which it 
was in charge for handling the connection to the user 
equipment. The user equipment hence knows the supporting 
network element such as the support node which handled its 
connections. This embodiment may be particularly applicable if 
the SGSN where the MS moved was not upgraded to find the 
appropriate old (i.e. previous) SGSN. 

The second network elements may also be MSCs (Mobile Switching 
Centres) or other types of serving elements, e.g. in circuit- 
switched networks. 

The solutions provided by the present invention are furthermore 
applicable in a case where network elements of different 
generation (such as 2G SGSN and a 3G SGSN) are provided which 
handle the connections for the same routing area. The selection 
of the support node may be made depending on the type of the 
connection established and/or requested, or on the type of the 
user equipment. As an example, the invention may be employed in 
a GERAN system (GSM/EDGE radio access network) . 

The present invention allows an effective adaptation of a 
cellular network being at least partly IP-based. IP networks 
are essentially peer-to-peer structured whereas the 
conventional cellular networks such as GSM, UMTS, etc. are 
typically based on an hierarchical architecture wherein a radio 
access network (RAN) or, in more detail, a controller 
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controlling the radio access such as a RNC, RNS, BTS, BSS and 
the like, is handled by a single serving node (e.g. MSC/VLR; 
SGSN; . . . ) . 

The invention generally proposes a structure and method wherein 
one network element providing e.g. radio access (e.g. RAN) to a 
user equipment is connected to many serving nodes such as core 
network (CN) nodes. This reduces the number of inter-CN-node- 
area update procedures and increases the reliability. The 
invention hence proposes a new architecture for a cellular 
system wherein one radio access network (or the network element 
providing or controlling the radio access) as well as a 
location area (LA) or routing area (RA) can be handled by many 
serving nodes of the same type. A routing function for deciding 
to which serving node the connection is to be made, is 
preferably located in the radio access network (RAN) or the 
respective network element providing or controlling the radio 
access, and is not located between the radio access network and 
the serving node, or in the serving node. The routing function 
located in the RAN additionally provides or comprises a method 
for selection of the serving node to connect to. 

Furthermore, the method and system according to the invention 
may be used to detect the node where a user equipment is 
actually registered, one of the network elements having a list 
of serving nodes serving the present location area (or routing 
area) of the user equipment. Preferably, this list includes a 
default serving node. The serving node to be used for handling 
the connection is preferably determined in the following 
manner: When the user equipment has not sent an identifier such 
as a core network (CN) identifier, the default serving node, if 
defined, will be selected from the list. If the user equipment 
has sent an identifier such as a CN identifier, a serving node 
corresponding to this identifier will be selected. The default 
serving node may be defined to be the serving node mentioned on 
a specific position of the list for the routing or location 
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area, e.g. the first serving node mentioned on the list. When 
no identifier is sent from the user equipment, the serving node 
mentioned on the specific place, e.g. the first-mentioned 
serving node, is selected by the RAN from the list. 

This method and structure can be used by the radio access 
network (or RAN controlling node or component) to find the 
serving node to be used. Likewise, this method and structure 
can be used by the new serving node to find the old serving 
node to which the user equipment was registered, or may be used 
by the new serving node to find the MSC/VLR to which the user 
equipment was registered, in particular in a case when the Gs 
interface is used. 

In accordance with one aspect of the invention, a user 
equipment such as a MS may be adapted to select a serving node 
by using a CN identifier. The CN identifier may be the latest 
used identifier, or may be a preconf igured, i.e. predetermined 
CN identifier which is stored in the user equipment, e.g. on a 
SIM card thereof. This aspect is claimed in claims 40 to 44. 

Furthermore, the method and system according to the invention 
may be used to allow many operators (each owning their own 
serving node) to share a common Radio Access Network (owned by 
another operator) . If every operator uses a different CN 
identifier, and if the MSs are configured to always use same CN 
identifier (even in the very first attach request) based on 
subscription information typically read from a SIM card, then 
the MS will always be connected to an SGSN owned by this 
operator (from which they bought SIM card) . 

The invention thus likewise provides a system as defined in 
claims 45 to 47, and/or network elements as defined in the 
further claims. 
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BRIEF DESCRIPTION OF THE FIGURES 

Fig. 1 shows a basic structure of one embodiment of a system in 
accordance with the invention; 

Fig. 2 illustrates the message flow for establishing a 
connection between a user equipment and a serving node; 

Fig. 3 shows a method for selecting a desired serving node; 

Fig. 4 illustrates a message flow in a system and method 
according to a further embodiment of the invention; 

Fig. 5 shows details of a table stored in a DNS server; 

Fig. 6 illustrates the method steps performed in a Routeing 
Area Update Procedure according to an embodiment of the 
invention related to UMTS; and 

Fig. 7 shows steps performed in a Combined Cell / URA Update 
and SRNS Relocation Procedure according to another embodiment 
of the invention. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION 

Fig. 1 shows the basic structure of an embodiment of a system 
in accordance with the invention. The system is implemented as 
a network 1, or forms a part thereof, which network 1 comprises 
at least one, or usually a plurality of, user equipments 2 
which, in this embodiment, are implemented as mobile stations 
MS. The user equipments may also be any other type of 
equipments such as stationary terminals. Although only one user 
equipment 2 is shown, usually several user equipments are 
attached to the network 1 and represent connection originating 
or terminating equipments. 
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In case of connection, or connection set-up, with another 
equipment forming part of network 1 or of another network, a 
radio connection to user equipment 2 is provided and handled by 
a radio access network (RAN) . The RAN comprises, in this 
embodiment, a radio network controller (RNC) 3 which is part 
of, or represents, the radio access network for radio 
connection to user equipment 2. Usually, several radio access 
networks and controllers 3 will be provided in the network 1 
for radio coverage of the different areas of the network 1. The 
RNC 3 (first network element) may be selectively connected to 
different serving nodes which, in this embodiment, are 
implemented as SGSNs 4 and 6. 

The network may comprise additional or alternative serving 
nodes such as mobile switching centres (MSCs) which normally 
will be combined with visitor location registers (VLRs) . The 
serving nodes 4, 6 may be connected, if necessary, to a gateway 
node 5 which here is a GGSN and provides the possibility of 
connection to other networks. 

In addition, a DNS (Domain Name System) server 7 is provided 
which may form part of network 1 or may be a network-external 
component. The DNS server 7 can be accessed by RNC 3, and 
usually also by other network components such as serving nodes 
4, 6 and/or gateway node 5. The communication possibilities are 
shown in Fig. 1 as double-headed arrows. 

The DNS server 7 comprises, or has access possibility to, a 
memory (not shown) storing lists (tables) of serving nodes 
available for alternatively covering routing areas or location 
areas of the network 1. 

Fig. 5 shows an example of a table stored in the memory. 
According to this example, the table contains several columns 
and rows. The left column "SGSN" lists the available serving 
nodes. SGSN1 may correspond to SGSN 4, SGSN2 may correspond to 
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SGSN 6, and SGSN3, SGSN4 may correspond to further serving 
nodes not shown in Fig. 1 and covering other routing or 
location areas of the network 1. The table furthermore, 
contains a column "IP address of SGSN" listing the IP addresses 
of the individual available serving nodes. The column "SGSN 
name" or "(SGSN identifier)" lists the identifiers identifying 
the individual serving nodes. In this example, the type of the 
node (2G or 3G) is built in the identifier. The column "Routing 
Area" lists the routing areas or location areas being covered 
by the individual serving nodes. As an example, the serving 
nodes SGSN1 SGSN2 , SGSN3 and SGSN4 are available for covering 
the same first routing area RA1 whereas the serving nodes SGSN1 
SGSN2, SGSN3 and SGSN5are available for alternatively covering 
a second routing area RA2 in which a mobile station may be 
located, e.g. after moving thereto from routing area RA1. 

Depending on the details of implementation of embodiments of 
the invention, the stored list does not necessarily contain all 
columns shown in Fig. 5. For instance, the column " SGSN" 
and/or "Routing area" (if all RAs handled by RNC use same CN 
identifier, and the list is specific per RNC) may be omitted. 
Alternatively, the list may also contain additional information 
useful for selecting an appropriate serving node. For instance, 
a column "serving node type" and/or a column indicating default 
nodes for some or all respective areas may be added. 

Generally, the architecture of a network or system according to 
the invention comprises two or more CN (Core Network) nodes of 
same type (e.g. MSC and/or SGSN) which are connected to the same 
radio access network or node RAN (e.g. BSS "base station sub- 
system"; UTRAN "UMTS Terrestrial Radio Access Network"; GERAN 
"GSM/EDGE Radio Access Network") and assigned to the same 
location area (LA) and/or routing area (RA) . One or more of the 
provided RANs contain, or are able to download from a network 
element such as the DNS server 7, a preconf igured list of CN 
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nodes. Preferably, the CN nodes are associated with a CN 
identifier which is unique at least for the assigned LA/RA. 

The system and method according to preferred embodiments of the 
invention are preferably structured in such a manner that each 
time when a user equipment registers into one location or 
routing area (e.g. by performing an Attach or Area Update 
procedure) , the CN node handling the registration returns its 
CN identifier to the user equipment, e.g. in the MM (Mobility 
Management) signalling. The user equipment is adapted to store 
a received CN identifier representing the serving node actually 
handling a connection. Furthermore, the user equipment may be 
designed to indicate the CN identifier (if known and/or if a 
re-establishment of the connection to a previously used CN is 
desired) , if desired, when the user equipment establishes a 
connection to the radio network. The CN identifier may be 
indicated for instance in the radio signalling, e.g. during RRC 
connection establishment. 

In order to ensure backward compatibility, the new information 
element (identifier such as CN identifier) is an optional 
information element transmitted in both MM and RRC signalling 
(if an explicit information element is used for both 
protocols) . This ensures that user equipments not supporting 
this feature will nevertheless work with new network elements. 
As such a user equipment is never sending the CN identifier, it 
is always connected to a CN node which is set as a default node 
to be selected when not receiving any CN identifier. Likewise, 
when the user equipment should move to a RAN not supporting 
this feature, the RNC is structured to ignore any CN identifier 
and to establish the connection always with the only CN node it 
is connected with. 

If the CN node does not support this feature, no CN identifier 
will be returned to the user equipment. The user equipment may 
be configured to erase previously stored CN identifier, so that 
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next time it is connected to the default node. In such a case, 
the user equipment is unable to transmit any CN identifier in 
the next connection request and will thus be connected to the 
default CN node provided for this area. In all these cases, the 
result is similar to existing systems. 

If one CN node is not supporting this feature, it shall be 
configured as the default CN node. 

When a GSM radio access (connection) is used in a GPRS-based 
network or other type of packet-based network, the TLLI 
(Temporary Logical Link Identifier) is sent to the base station 
controller BSC with every packet transfer. When considering to 
add a separate CN identifier, a heavy radio load would result 
as the CN identifier would have to be sent with every packet 
transfer as well. According to one embodiment of the invention, 
the CN identifier will be sent implicitely, i.e. encoded within 
the TLLI. It should be noted that TLLI is always derived from 
PTMSI, by changing the three first bits. . This coding may be 
effected by coding the temporary identity (PTMSI and TLLI) in a 
defined way, for instance using the 4 last bits to indicate CN 
identifier. This solution does neither increase the radio nor 
the signalling load. When sending a Routing Area Update (RAU) 
and/or Attach Request message, the user equipment automatically 
sends the old TLLI. The new PTMSI coded so as to contain the CN 
identifier of the serving network element serving the 
connection, is sent back in the RAU/Attach response message on 
the radio signalling level. Thus, this feature of transmitting 
a CN identifier can be introduced to a GPRS-based network 
without changes of the protocols. But it requires the BSC to 
implement the method described in this invention to select the 
right SGSN for every packet transfer. 

In an UMTS network, the above solution is likewise applicable, 
but would require the RNC to read the PTMSI sent in L3 MM 
messages, which are presently only relayed by RNC. Here, 
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however, it is preferred to introduce a new information element 
(i.e. to send CN identifier explicitely) for identifying the 
serving node in charge of the connection to the user equipment. 
In an UMTS network, the RNC keeps the RRC context. Therefore, 
when including the CN identifier into the RRC context, it is 
not necessary to send the CN identifier often. 

In a GPRS network (both GSM and UMTS) , there is an additional 
problem occurring during an inter-SGSN-Routing Area Update. 
During such hand-over, the new SGSN needs to find the old SGSN 
which handled the connection to the user equipment up to now. 
For instance, PDP (Packet Data Protocol) context information 
must be transferred from old SGSN to the new SGSN. 

In accordance with an embodiment of the invention, the user 
equipment preferably includes the CN identifier in the RA 
(Routing Area) Update Request message, and the DNS server 5 
returns, upon a respective query from the RNC 3 indicating the 
old routing area identifier, a list of IP addresses of SGSNs in 
charge of the routing area. A CN identifier is implicitly or 
explicitly associated with every IP address, such as shown in 
Fig. 5. The CN identifier is implicitly indicated if the 
position on the list indicates the CN identifier. In such a 
case, it is not necessary to separately transmit the CN (e.g. 
SGSN) identifier. When, in the list example shown in Fig. 5, 
the routing area identifier designates the routing area RA 1, a 
list is returned from DNS server 7 to RNC 3 containing SGSN1 
and SGSN2 and indicating the IP addresses thereof. 

When explicitly transmitting the CN identifiers, the associated 
identifiers "2G_SGSN IDENTIFIER_13" and "3G_SGSN IDENTIFIER_14" 
are transmitted associated with the IP addresses. In particular 
the Canonical name associated with the IP address is returned 
from DNS server 7 to RNC 3 which represents the value of the CN 
identifier. This concept effectively uses the structure of DNS 
which is based on Canonical name (CNAME) or alias, as defined 
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in e.g. RFC 1034 and 1035. Therefore, as part of the response 
of the DNS, there is a transmitted a list of IP addresses and 
Canonical names (CNAME) , as indicated in Fig. 5 by the two 
center columns and the rows associated to the same routing area 
(e.g. RA1) , respectively. 

With this feature, the RNC or BSC can easily select the 
appropriate SGSN on the basis of the technology used by the 
user equipment and of the SGSN identifier, which can be 
recognised from e.g. TLLI in GPRS, and extended CN identifier 
in UMTS, as mentioned above. 

When the CN identifier is only implicitly indicated, it is 
represented by the position on the list. For instance, when not 
sending the SGSN NAME identifier, the first SGSN1 is determined 
as the SGSN to be used for handling the connection of the user 
equipment in routing area 1, This SGSN thus serves e.g. as a 
default serving node to be used for connection handling when no 
CN identifier (SGSN identifier) is indicated. 

Otherwise, the SGSN having an assigned CN identifier which 
corresponds to the CN identifier indicated by user equipment 2, 
will be selected as SGSN for handling the connection, or for 
transmitting the context information to the new SGSN. In the 
latter case of inter-SGSN-handover , the new SGSN can detect the 
old SGSN on the basis of the CN identifier and the area 
identifier which identifies the old ■ SGSN and have been 
transmitted (explicitly or implicitly for CN identifier) from 
the user equipment in subsequent messages, e.g. together with 
PTMSI. The RAN or new SGSN can therefore detect e.g. the IP 
address of the old SGSN when sending a query to the DNS server 
7. 

Alternatively, a master SGSN may be provided which, when not 
handling the PDP context itself, acts as a relay and determines 
the old SGSN based on e.g. CN identifier. The DNS server 7, or 
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alternatively or additionally, the master SGSN may have a list 
of SGSNs mapped to the RAI (RA1, RA2 in the column "ROUTING 
AREA" of Fig. 5) . In the latter case, it is not indispensably 
necessary to provide the DNS server with such a list of SGSNs 
mapped to the RAIs. 

This information on the old SGSN may be used by the new SGSN 
for changing all PDP contexts contained in the old SGSN to the 
new SGSN for a user equipment or even for all user equipments, 
in particular when intending to perform maintenance operations 
of the old SGSN such as software-updating. 

The list of SGSN addresses and SGSN identifiers may be modified 
in case of need to use another SGSN to serve one or more SGSN 
identifiers. Subsequent signalling connections will then be 
made to this another SGSN when sending these SGSN identifiers. 
This also requires the updating of GTP tunnels for the existing 
PDP contexts, etc. 

Fig. 2 refers to a case, in which the radio access network 
controller such as RNC 3 used the proposed method to determine 
which SGSN to use for handling a connection to a user equipment 
MS 2. In a step 1), MS 2 sends a request, e.g. a RRC connection 
message, optionaly including the CN identifier identifying the 
serving node in which the MS 2 may be registered. The RNC 3 
detects the new RAI directely from the cell where the MS is 
located.. Then the RNC selects the SGN by using a list as 
depicted in figure 5 and the proposed method. This list may be 
preconf igured in RNC or retrieved from another network element 
like showed by step 2) and 3) . 

In a step 2), the RNC sends a request to the DNS server 7 
requesting a list of SGSNs available for the routing area. This 
request indicates the routing area identity RAI. The DNS server 
7 checks the table memory containing the SGSN list such as 
shown in Fig. 5, by selecting only those SGSNs corresponding to 
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the indicated routing area. In a step 3.), the DNS server 7 
returns the list of selected SGSNs to the RNC 3. 
As an alternative to steps 2.) and 3.), the RNC 3 may also 
send, in step 2.) additionally, or only, the CN identifier 
received from MS 2, to the DNS server 7. The DNS server 7 is, 
in this case, preferably adapted to use the CN identifier for 
selection of the appropriate SGSN from the list, and returns, 
in step 3.) merely the IP address of the appropriate SGSN. The 
RNC 3 will then establish, in steps 4.) to 6.), a connection 
using this single received IP address of the desired SGSN. 

The RNC 3 selects one SGSN according to the following proposed 
method: 

If the CN Id is was sent in the signalling, the RNC use the 
CNid as a key and the area to select the right serving node. 
Note that the area do not need to be used in the special case 
where the area(s) handled by RNC have same configuration (e.g. 
RNC handle only one RA) . 

In addition, the RNC may check the type of the serving node. In 
a UMTS system, an RNC when handling a packet connection, needs 
to select a serving node of SGSN type (and not MSC/VLR) . In 
addition, if there are different SGSN types (e.g. 2G and 3G) , 
the RNC need to select an appropriate one, i.e. a 3G SGSN for 
an RNC. 

If the RNC finds a suitable serving node, it will use the 
serving node address indicated in the list to establish the 
connection . 

If the RNC does not find a suitable node, it could select 
any serving node of the suitable type supporting this area. 
This selection may be done randomly to spread the load, based 
on prefered serving node(s) (e.g. located close to RNC), or 
based on known information of the respective load of charging 
nodes (e.g. from operation and maintenance or DNS system) to 
select the less loaded serving node, or a combination of the 
above . 
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If the CN Id is was not sent in the signalling, the RNC could 
select the serving node according to either of the following 
embodiment : 

In a first prefered embodiment, where all MS are assumed 
to support sending of CN identifier (e.g. a GPRS system where 
CN identifier is implicitely coded as part of the TLLI), the 
RNC could select any serving node of the suitable type 
supporting this area. This selection may be done randomly to 
spread the load, based on prefered serving node(s) (e.g. 
located close to RNC) , or based on known information of the 
respective load of charging nodes (e.g. from operation and 
maintenance procedures , or DNS system) to select the less loaded 
serving node, or a combination of the above. If some of the 
information above is implicitely indicated by the order of the 
list (e.g. Serving nodes ranked from less loaded to more 
loaded) the RNC 3 is preferably adapted to select an SGSN 
indicated at a specific place of the list. 

In a second prefered embodiment, where some MS (typically 
legacy MS) are assumed not to support sending of CN identifier 
(e.g. first generation UMTS mobiles will not send CN identifier 
as part of RRC signaling) , the RNC has to select a default 
serving node for this area. This is needed to be sure that next 
time a connection is established from same mobile (still not 
indicated its CN identifier) , the same node is selected again. 
Of course as the default is unique per area, a new serving node 
may be selected when the area changes (similar to existing 
behaviour) . In addition, when the serving node changes, in 
system such as GPRS, the new serving node needs to find the old 
serving node. The new serving node will need to also use the 
default serving node handling the old area when no CN 
identifier is sent. This way the address of the old serving 
node can always be retrieved unambiguously) . 
The RNC 3 subsequently performs, in the known manner, the 
necessary steps for establishing the connection between the MS 
2 and the selectedSGSN 4. (proposal: move that together with 
fig 5 description illustrating another type of additional 
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column: In addition, or as an alternative, the list of SGSNs 
sent in response 3.) may contain additional information such as 
load information to be checked by RNC 3 for determining on the 
SGSN to be selected.) 

The connection to the selected SGSN may fail, in this case the 
RNC may retry with another Serving node of the appropriate type 
supporting this area. 

If the selected SGSN (and the connection fail) was the default 
SGSN according to the second prefered embodiment, a new SGSN 
may be selected as the default, typically a secondary default. 
In this case, when the serving node is changing, the new 
serving node will try first to connect to the default (as 
previously) . If the default SGSN is down or not knowing the 
user, the new SGSN should retry using the secondary default 
serving node handling the old area when no CN identifier is 
sent. This way the address of the old serving node can always 
be retrieved unambiguously. 

When a SGSN is scheduled for operation and maintenance 
procedures, it will preferably be excluded from the list sent 
back in response to 3.) a certain or determined time interval 
such as several hours before the scheduled maintenance time 
point so as to avoid connections to be newly established to 
this SGSN. In this case, the DNS server 7 will be informed by 
the operation and maintenance system on the SGSN(s) scheduled 
for maintenance operations, and will either no longer select 
such an SGSN from the list, or will exclude same, when having 
retrieved the available SGSNs from the memory, from 
transmission to the RNC 3. Therefore, when the SGSN is shut 
down for operation and maintenance procedures, the number of 
registered user in this SGSN is minimum. These user connection 
may just be lost, or they may be sent to a new SGSN configured 
to use for this area the same CN identifier as the SGSN being 
shut down. 
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The steps 4.) to 6.) shown in Fig. 2 for establishing the 
connection between MS 2 and SGSN 4 are the customary ones and 
are therefore not explained in detail. 

( I do not update Fig 3 and 4, as I think they are covered by 
fig 2 description, but please double check it) 
Fig. 3 refers to a case where the MS 2 is intending to be 
connected to a certain SGSN 6, e.g. when re-establishing a 
connection. In this case, the MS 2 sends a request such as a 
RRC message which includes an SGSN identifier identifying the 
desired SGSN 6. In the request 1.), the routing area identity 
(RAI) or location area identity (LAI) can be additionally 
indicated. 

As an alternative, the RNC 3 can deduce the routing (or 
location) area, and thus the routing (or location) area 
identity, from other parameters. Similar to step 2.) of Fig. 2, 
the RNC 3 requests, in a step 2.) of Fig. 3, the DNS server 7 
to send back a list of SGSNs by indicating location position 
such as RAI as a selection criterion. The DNS server 7 
retrieves from the serving node list such as shown in Fig. 5 a 
sub-list of IP addresses and identifiers of SGSNs corresponding 
to, and being able to serve, the indicated location area. The . 
DNS server 7 returns this sub-list to RNC 3 a response in step 
3.). The RNC 3 selects that SGSN (here: SGSN 6) from the sub- 
list received in step 3.) which corresponds to the SGSN 
identifier indicated by MS 2 in step 1.), and performs the 
known connection steps 4.) to 6) for establishing the 
connection between MS 2 and the desired SGSN 6. 

As an alternative to steps 2.) and 3.), the RNC 3 may also 
send, in step 2.) additionally, or only, the SGSN identifier 
received from MS 2, to the DNS server 7. The DNS server 7 is, 
in this case, preferably adapted to use the SGSN identifier for 
selection of the appropriate SGSN from the list, and returns, 
in step 3.) merely the IP address of the appropriate SGSN. The 
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RNC 3 will then establish, in steps 4.) to 6.), a connection 
using this single received IP address of the desired SGSN. 

Fig. 4 shows an alternative or additional function of the same 
or another embodiment of the method and system in accordance 
with the invention. According to Fig. 4, one of the SGSNs, here 
the SGSN 4, is set as a default SGSN for a specific routing 
area RA. Similar to step 1.) of Figs. 2 and 3, the step 1.) of 
Fig. 4 consists in sending a message such as a RRC connection 
request, from MS 2 to RNC 3, indicating the routing area 
identifier RAI . The RNC 3 recognises from the lack of any SGSN 
identifier requesting a connection to a specific SGSN, the 
possibility of selecting the default SGSN for the indicated 
routing area. The RNC 3 then inquires, in step 2.) a database 8 
for returning the address of the default SGSN 4, and indicates 
the routing area identity in the inquiring message. The 
database 8 may be structured similar to the table shown in Fig. 
5 and may be contained in, or accessible by, a DNS server 7, or 
another server. The database 8 returns, in response 3.), the 
address of the default SGSN which address is used by RNC 3 in 
the customary manner for establishing a connection between MS 2 
and the default SGSN 4, as represented by steps 4.) to 6.). 

Fig. 6 shows the steps of a Routeing Area Update Procedure in a 
preferred implementation of the invention, related to UMTS. 
Some of the modifications of this embodiment, as compared to 
the specifications, are emphasized by using bold letters. 

A routeing area update takes place when an attached MS detects 
that it has entered a new RA or when the periodic RA update 
timer has expired. The SGSN detects that it is an intra SGSN 
routeing area update by noticing that it also handles the old 
RA. In this case, the SGSN has the necessary information about 
the MS and there is no need to inform the GGSNs or the HLR 
about the new MS location. A periodic RA update is always an 
intra SGSN routeing area update. If the network operates in 
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mode I, then an MS that is both GPRS-attached and IMSI-attached 
shall perform the Combined RA / LA Update procedures. 
In UMTS, an RA update is either intra-SGSN or inter-SGSN RA 
update, either combined RA / LA update or only RA update, 
either initiated by an MS in PMM-CONNECTED or in PMM-IDLE 
state. All the RA update cases are contained in the procedure 
illustrated in Fig. 6. 

The steps shown in Fig. 6 for performing a UMTS RA Update 
Procedure will be described using the step numbering of Fig. 6. 



1 ) The RRC connection is established, if not already done. The MS sends a Routeing Area 
Update Request message (P-TMSI, old RAI, old P-TMSI Signature, Update Type, 
follow on request, CN identifier) to the new SGSN using on the radio interface an 
RRC message (Initial direct transfer or uplink direct transfer) including the CN 
identifier if stored in the MS. The CN identifier and the old RAI is used by the 
new SGSN to find the old SGSN. Follow on request shall be set by MS if there is 
pending uplink traffic (signalling or user data). The SGSN may use, as an 
implementation option, the follow on request indication to release or keep the Iu ' 
connection after the completion of the RA update procedure. Update Type shall 
indicate: 

- RA Update if the RA Update is triggered by a change of RA; 

- Periodic RA Update if the RA update is triggered by the expiry of the Periodic RA 
Update timer; 

- Combined RA / LA Update if the MS is also IMSI-attached and the LA update shall 
be performed in network operation mode I (see subclause "Interactions Between 
SGSN and MSC/VLR"); or 

- Combined RA / LA Update with IMSI attach requested if the MS wants to perform 
an IMSI attach in network operation mode I. 
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The SNRC shall send the request to the SGSN corresponding to the CN identifier 
sent by the MS according to a list preconfigured in the RNC. If no CN identifier 
has been sent, the default SGSN for this area shall be selected (in order to support 
legacy MS). 

Note: If this RNC is not connected to the old SGSN, a new SGSN shall be selected. 
The SGSN having in this area same CN identifier as the old one will be selected, or 
if not existing, another one. 

The SRNC shall add the Routeiag Area Identity including the RAC and LAC of the area 
where the MS is located before forwarding the message to the 3G-SGSN. This RA 
identity corresponds to the RAI in the MM system information sent by the SRNC to the 
MS. 

NOTE: Sending the Routeing Area Update Request message to the SGSN triggers the 
establishment of a signalling connection between UTRAN and SGSN for the 
concerned MS. 

2) If the RA update is an Inter-SGSN Routeing area update and if the MS was in 
PMM-IDLE state, the new SGSN sends SGSN Context Request message (old P-TMSI, 
old RAI, old P-TMSI Signature) to the old SGSN to get the MM and PDP contexts for 
the MS. The old SGSN validates the old P-TMSI Signature and responds with an 
appropriate error cause if it does not match the value stored in the old SGSN. This 
should initiate the security functions in the new SGSN. If the security functions 
authenticate the MS correctly, the new SGSN shall send an SGSN Context Request 
(IMSI. old RAI, MS Validated) message to the old SGSN. MS Validated indicates that 
the new SGSN has authenticated the MS. If the old P-TMSI Signature was valid or if 
the new SGSN indicates that it has authenticated the MS, the old SGSN responds with 
SGSN Context Response (Cause, IMSI, MM Context, PDP contexts). If the MS is not 
known in the old SGSN, the old SGSN responds with an appropriate error cause. The 
old SGSN starts a timer. 

3) Security functions may be executed. These procedures are defined in subclause 
"Security Function". If the security functions do not authenticate the MS correctly, then 
the routeing area update shall be rejected, and the new SGSN shall send a reject 
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indication to the old SGSN. The old SGSN shall continue as if the SGSN Context 
Request was never received. 

4) I T the RA update is an Inter-SGSN Routeing area update, the new SGSN sends an SGSN 
Context Acknowledge message to the old SGSN. The old SGSN marks in its context 
that the MSC/VLR association and the information in the GGSNs and the HLR are 
invalid. This triggers the MSC/VLR, the GGSNs, and the HLR to be updated if the MS 
initiates a routeing area update procedure back to the old SGSN before completing the 
ongoing routeing area update procedure. 

5) If the RA update is an Inter-SGSN RA Update and if the MS was in PMM-IDLE state, 
the new SGSN sends Update PDP Context Request (new SGSN Address, QoS 
Negotiated, Tunnel Endpoint Identifier, ) to the GGSNs concerned. The GGSNs update 
their PDP context fields and return an Update PDP Context Response (Tunnel Endpoint 
Identifier). Note: If the RA update is an Inter-SGSN routeing area update initiated by an 
MS in PMM-CONNECTED state, then the Update PDP Context Request message is 
sent as described in the specification subclause "Serving RNS Relocation Procedures". 

6) If the RA update is an Inter-SGSN RA Update, the new SGSN informs the HLR of the 
change of SGSN by sending Update Location (SGSN Number, SGSN Address, IMSI) to 
the HLR. 

7) If the RA update is an Inter-SGSN RA Update, the HLR sends Cancel Location (IMSI, 
Cancellation Type) to the old SGSN with Cancellation Type set to Update Procedure. If 
the timer described in step 2 is not running, then the old SGSN removes the MM 
context. Otherwise, the contexts are removed only when the timer expires. It also 
ensures that the MM context is kept in the old SGSN in case the MS initiates another 
inter SGSN routeing area update before completing the ongoing routeing area update to 
the new SGSN. The old SGSN acknowledges with Cancel Location Ack (IMSI). 

8) If the RA update is an Inter-SGSN RA Update, the HLR sends Insert Subscriber Data 
(IMSI, subscription data) to the new SGSN. The new SGSN validates the MS's presence 
in the (new) RA. If due to regional subscription restrictions the MS is not allowed to be 
attached in the RA, the SGSN rejects the Routeing Area Update Request with an 
appropriate cause, and may return an Insert Subscriber Data Ack (IMSI, SGSN Area 
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Restricted) message to the HLR. If all checks are successful then the SGSN constructs 
an MM context for the MS and returns an Insert Subscriber Data Ack (IMSI) message to 
the HLR. 

9) If the RA update is an Inter-SGSN RA Update, the HLR acknowledges the Update 
Location by sending Update Location Ack (IMSI) to the new SGSN. 

1 0) If Update Type indicates combined RA / LA update with IMSI attach requested, or if 
the LA changed with the routeing area update, then the association has to be established, 
and the new SGSN sends a Location Update Request (new LAI, IMSI, SGSN Number, 
Location Update Type) to the VLR. Location Update Type shall indicate IMSI attach if 
Update Type in step 1 indicated combined RA / LA update with ISI attach requested. 
Otherwise, Location Update Type shall indicate normal location update. The VLR 
number is translated from the RAI via a table in the SGSN. The SGSN starts the 
location update procedure towards the new MSC/VLR upon receipt of the first Insert 
Subscriber Data message from the HLR in step 8). The VLR creates or updates the 
association with the SGSN by storing SGSN Number. 

11) If the subscriber data in the VLR is marked as not confirmed by the HLR, the new 
VLR informs the HLR. The HLR cancels the old VLR and inserts subscriber data in the 
new VLR (this signalling is not modified from existing GSM signalling and is included 
here for illustrative purposes): 

a) The new VLR sends an Update Location (new VLR) to the HLR. 

b) The HLR cancels the data in the old VLR by sending Cancel Location (IMSI) to the 
old VLR. 

c) The old VLR acknowledges with Cancel Location Ack (IMSI). 

d) The HLR sends Insert Subscriber Data (IMSI, GSM subscriber data) to the new VLR. 

e) The new VLR acknowledges with Insert Subscriber Data Ack (IMSI). 
0 The HLR responds with Update Location Ack (IMSI) to the new VLR. 

1 2) The new VLR allocates a new TMSI and responds with Location Update Accept (VLR 
TMSI) to the SGSN. VLR TMSI is optional if the VLR has not changed. 
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13) The new SGSN validates the MS's presence in the new RA. If due to roaming 
restrictions the MS is not allowed to be attached in the SGSN, or if subscription 
checking fails, then the SGSN rejects the routeing area update with an appropriate 
cause. If all checks are successful then the new SGSN establishes MM context for the 
MS. The new SGSN responds to the MS with Routeing Area Update Accept (P-TMSI, 
VLR TMSI, P-TMSI Signature, new CN identifier). 

1 4) The MS confirms the reallocation of tbe TMSIs by returning a Routeing Area Update 
Complete message to the SGSN. 

1 5) The new SGSN sends a TMSI Reallocation Complete message to the new VLR if the 
VLR TMSI is confirmed by the MS. 

NOTE: Steps 11, 12, and 15, are performed only if step 9 is performed. 

Note: This case assumes no change on the Gs interface, and 

corresponds to the case where one LA is still handled by a 

single MSC/VLR. So SGSN derives the MSC/VLR address from LAI 
(current solution) . 

In the case where many MSC/VLR would handle the same LA, and Gs 
interface is used, the solution presented above should be 
enhanced by adding CN identifier (eventually associated with a 
CN type indicating CS) to message 1 (Routing area update 
request) and to message 13 (Routing area update accept) . In 
addition CN identifier should be added in Gs interface to 
message 10 (Location update request) and to message 12 
(Location update accept) . This supposes that the SGSN is 
capable of deriving MSC address from LAI and CN identifier, or 
at least from only LAI (as long as one SGSN always selects same 
MSC address for same LA, no .unnecessary inter MSC/VLR location 
update is performed if SGSN do not change) . 
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Another example of a procedure where the method to select 
serving node based on CN identifier may be used, is a Combined 
Cell / URA Update and SRNS Relocation Procedure. 

This procedure is only performed for an MS in PMM- CONNECTED 
state, where the Iur carries control signalling but no user 
data . 

The Combined Cell / URA Update and SRNS Relocation procedure is 
used to move the UTRAN to CN connection point at the UTRAN side 
from the source SRNC to the target RNC , while performing a cell 
re-selection in the UTRAN. In the procedure, the Iu links are 
relocated. If the target RNC is connected to the same SGSN as 
the source SRNC, an Intra SGSN SRNS Relocation procedure is 
performed. If the routeing area is changed, then this procedure 
is followed by an Intra SGSN Routeing Area Update procedure. 
The SGSN detects that it is an intra-SGSN routeing area update 
by noticing that it also handles the old RA. In this case, the 
SGSN has the necessary information about the MS and there is no 
need to inform the HLR about the new MS location. 

Before the Combined Cell / URA Update and SRNS Relocation and 
the Routeing Area Update the MS is registered in the old SGSN. 
The source RNC is acting as serving RNC. 

After the Combined Cell / URA Update and SRNS Relocation and 
the Routeing Area Update, the MS is registered in the new SGSN 
The MS is in state PMM-CONNECTED towards the new SGSN, and the 
target RNC is acting as serving RNC. 

The Combined Cell / URA Update and SRNS Relocation procedure 
for the PS domain is illustrated in Fig. 7. The sequence is 
valid for both intra-SGSN SRNS relocation and inter-SGSN SRNS 
relocation. The steps will be described by referring to the 
numbering shown in Fig. 7. 
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1 ) The MS sends a Cell Update / URA Update message to the UTRAN, after having made 
cell re-selection. Upon reception of the message, the target RNC forwards the received 
message towards the source SRNC via Iur. Source SRNC decides to perform a 
combined cell / URA update and SRNS relocation towards the target RNC. 

2) The source SRNC initiates the relocation preparation procedure by sending a Relocation 
Required message (Relocation Type, Cause, Source ID, Target ID, Source RNC to 
Target RNC Transparent Container) to the old SGSN. The source SRNC shall set 
Relocation Type to "UE not involved". Source RNC to Target RNC Transparent 
Container includes the necessary information for Relocation co-ordination, security 
functionality, and RRC protocol context information (including UE Capabilities). 

3) The old SGSN determines from Target ID if the SRNS Relocation is intra SGSN SRNS . 
relocation or inter SGSN SRNS relocation. In case of inter SGSN SRNS relocation the 
old SGSN initiates the relocation resource allocation procedure by sending a Forward 
Relocation Request (IMSI, Tunnel Endpoint Identifier Signalling, MM Context, PDP 
Context, Target Identification, UTRAN Transparent Container, RANAP Cause) 
message to the new SGSN. The new SGSN address is derived from the target ID 
and the CN identifier which was previously sent to the MS. . At the same time a 
timer is started on the MM and PDP contexts in the old SGSN, see Routeing Area 
Update procedure in subclause "Location Management Procedures (UMTS Only)". The 
Forward Relocation Request message is applicable only in case of inter SGSN SRNS 
relocation. 

4) The new SGSN sends a Relocation Request message (Permanent NAS UE Identity, 
Cause, CN Domain Indicator, Source RNC to Target RNC Transparent Container, 
RABs To Be Setup) to the target RNC. For each RAB requested to be established, 
RABs To Be Setup shall contain information such as RAB ID, RAB parameters, 
Transport Layer Address, and Iu Transport Association. The RAB ID information 
element contains the NSAPI value, and the RAB parameters information element gives 
the QoS profile. The Transport Layer Address is the SGSN Address for user data, and 
the Iu Transport Association corresponds to Tunnel Endpoint Identifier Data. 
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After all necessary resources for accepted RABs including the Iu user plane are 
successfully allocated, target RNC shall send the Relocation Request Acknowledge 
(RABs setup, RABs failed to setup) message to the new SGSN. Target RNC will for 
each RAB to be setup (defined by an IP Address and a Tunnel Endpoint Identifier) 
receive both forwarded downstream PDUs from the source SRNC as well as 
downstream PDUs from the new SGSN. 

i 

5) When resources for the transmission of user data between target RNC and new SGSN 
has been allocated and the new SGSN is ready for relocation of SRNS, the Forward 
Relocation Response message (Cause, RANAP Cause, and Target RNC Information) is 
sent from new SGSN to old SGSN. This message indicates that the new SGSN and 
target RNC are ready to receive from source SRNC the downstream packets not yet 
acknowledged by MS, i.e., the relocation resource allocation procedure is terminated 
successfully. RANAP Cause is information from the target RNC to be forwarded to the 
source RNC. The Target RNC Information, one information element for each RAB to be 
setup, contains the RNC Tunnel Endpoint Identifier and RNC IP address for data 
forwarding from source SRNC to target RNC. The Forward Relocation Response 
message is applicable only in case of inter SGSN SRNS relocation. 

6) The old SGSN continues the relocation of SRNS by sending a Relocation Command 
(RABs to be released, and RABs subject to data forwarding) message to the source 
SRNC. The old SGSN decides the RABs subject to data forwarding based on QoS, and 
those RABs shall be contained in RABs subject to data forwarding. For each RAB 
subject to data forwarding, the information element shall contain RAB ID, Transport 
Layer Address, and Iu Transport Association. The Transport Layer Address and Iu 
Transport Association is used for forwarding of DL N-PDU from source RNC to target 
RNC. 

7) Upon reception of the Relocation Command message from the PS domain, the source 
RNC shall start the data-forwarding timer. When the relocation preparation procedure is 
terminated successfully and when the source SRNC is ready, the source SRNC shall 
trigger the execution of relocation of SRNS by sending a Relocation Commit (SRNS 
Contexts) message to the target RNC. The purpose of this procedure is to transfer SRNS 
contexts from the source RNC to the target RNC. SRNS contexts are sent for each 
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concerned RAB and contain the sequence numbers of the GTP-PDUs next to be 
transmitted in the uplink and downlink directions and the next PDCP sequence numbers 
that would have been used to send and receive data from the MS. For connections using 
RLC unacknowledged mode PDCP sequence numbers is not used. 

8) After having sent the Relocation Commit message, source SRNC begins the forwarding 
of data for the RABs subject to data forwarding. The data forwarding at SRNS 
relocation shall be carried out through the Iu interface, meaning that the data exchanged 
between source SRNC and target RNC are duplicated in the source SRNC and routed at 
IP layer towards the target RNC. 

9) The target RNC shall send a Relocation Detect message to the new SGSN when the 
relocation execution trigger is received. For SRNS relocation type "UE not involved", 
the relocation execution trigger is the reception of the Relocation Commit message from 
the Iur interface. When Relocation Detect message is sent, target RNC shall start SRNC 
operation. 

1 0) After having sent the Relocation Detect message, target SRNC responds to the MS by 
sending a Cell Update Confirm / URA Update Confirm message. Both messages contain 
UE information elements and CN information elements. The UE information elements 
include among others new SRNC identity and S-RNTI. The CN information elements 
contain among others Location Area Identification and Routeing Area Identification. 
The procedure shall be co-ordinated in all Iu signalling connections existing for the MS. 

1 1) Upon reception of Relocation Detect message, CN may switch the user plane from 
source RNC to target SRNC. If the SRNS Relocation is an inter SGSN SRNS 
relocation, the new SGSN sends Update PDP Context Request messages (new SGSN 
Address, SGSN Tunnel Endpoint Identifier, QoS Negotiated) to the GGSNs concerned. 
The GGSNs update their PDP context fields and return an Update PDP Context 
Response (GGSN Tunnel Endpoint Identifier) message. 

1 2) When the MS has reconfigured itself, it sends the RNTI Reallocation Complete 
message to the target SRNC. 

1 3) When target SRNC receives the RNTI Reallocation Complete message, i.e. the new 
SRNC-ID + S-RNTI are successfully exchanged with the UE by the radio protocols, 
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target SRNC shall initiate the Relocation Complete procedure by sending the Relocation 
Complete message to new SGSN. The purpose of Relocation Complete procedure is to 
indicate by the target SRNC the completion of relocation of SRNS to the CN. If the user 
plane has not been switched at Relocation Detect, the CN shall upon reception of 
Relocation Complete switch the user plane from source RNC to target SRNC, If the 
SRNS Relocation is an inter SGSN SRNS relocation, the new SGSN signals to the old 
SGSN the completion of the SRNS relocation procedure by sending a Forward 
Relocation Complete message. 

14) Upon receiving the Relocation Complete message or if it is an inter SGSN SRNS 
relocation; the Forward Relocation Complete message, the old SGSN sends an Iu 
Release Command message to the source RNC. When the RNC data-forwarding timer 
has expired the source RNC responds with an Iu Release Complete. 

1 5) After the MS has finished the Cell / URA update and RNTI reallocation procedure 
and if the new Routeing Area Identification is different from the old one, the MS 
initiates the Routeing Area Update procedure. See subclause "Location Management 
Procedures (UMTS Only)". Note that it is only a subset of the RA update procedure 
that is performed, since the MS is in PMM-CONNECTED state. 

Note that when the RAU procedure is performed, the MS 
indicates the same CN identifier as used by old SGSN to find 
the new SGSN , so that the SGSN that is selected by the new 
SRNC, is the same as the one that has already been selected 
by the old SGSN. 

An alternative solution would be that the old SGSN selects 
anyone of the SGSN capable to connect to the target RNC based 
on target ID. Then the new SGSN sends its CN identifier to 
the MS, e.g. by adding CN identifier in message 4 (Relocation 
Request) and 10 (Cell Update Confirm / URA Update Confirm 
message) . Then the MS uses the CN id for the update selecting 
the right SGSN. 
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In a prefered implementation, the coding of the CN identifier 
is optimised to allow enough serving nodes to handle the same 
area, but not to increase too much radio signaling. The 
preferred coding is therefore to use 4 bits, providing 16 
serving nodes but not much overhead. 

Also to simplify implementation, a given code (e.g. 0000) 
should indicate the default serving node for all areas. And 
another code (e.g. 0001) should indicate the secondary default 
serving node. This implementation would reduce need to 
configure an additional parameter as default. In addition, when 
a node (e.g. RNC) selects the default, it can be implemented as 
using known default value of CN identifier (e.g. 0000) to query 
the list and retrieve (default) serving node address. 

Concerning Gs interface and a simultaneous PS/CS attachment, if 
an association between the SGSN and the MSC is created (e. g. 
the UE (user equipment) performs a combined PS / CS attach), 
the SGSN is provided with, or has access to, a translation 
table to derive the MSC address from the RAI . Changes are' 
needed to the translation table if multiple MSCs may control 
the same location area. An additional identifier, the MSC 
Identifier, may be provided to find a specific MSC controlling 
a location area. 

Although preferred embodiments have been described above, the 
invention is not limited thereto and may also be implemented in 
networks of different types using serving nodes of different 
structure such as MSC/VLR. 

Also the claims should be taken in their broad meaning, so that 
target ID which identifies an element handling an area, can in 
fact be considered as the identifier of an area, i.e. the area 
handled by this element. 
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CLAIMS 

1. System for providing a connection in a communication network 
comprising several network elements and being adapted to route 
a connection via a first network element and one or more of 
alternatively selectable second network elements, at least one 
of the network elements storing a list of second network 
elements selectable by first network element, said list being 
accessible using an identifier identifying an area and/or an 
identifier identifying a desired second network element, said 
identifiers being transmitted from another network element. 

2. System according to claim 1, wherein the area identifier is 
a Location or Routing Area Identifier (RAI)or target ID, at 
least two second network elements being assigned to the same 
identifier . 

3. System according to any one of the preceding claims, wherein 
the identifier is a CN identifier. 

4. System according to any one of the preceding claims, wherein 
information on at least two second network elements being 
assigned to the transmitted identifier is sent to the first 
network element. 

5. System according to any one of the preceding claims, wherein 
the list of selectable second network elements is sent to the 
first network element in a defined order. 
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6. System according to claim 5, wherein the order is depending 
on the load of the second network elements indicated in the 
list. 

7. System according to claim 5 or 6, wherein the order is 
depending on the geographical distance between the first and 
the second network elements. 

8. System according to claim 5, 6, or 7, wherein the order is 
depending on the address of the first network element. 

9. System according to any one of the preceding claims, wherein 
the network is a packet-switched network. 

10. System according to any one of the preceding claims, 
wherein the first network element provides radio access to one 
or more user equipments. 

11. System according to any one of the preceding claims, 
wherein the second network elements are serving nodes, 
preferably SGSNs. 

12. System according to any one of the preceding claims, 
wherein the at least one network element storing the list is a 
DNS server. 
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13. System according to claim 12, wherein the DNS server is 
adapted to return a list of IP addresses of second network 
elements . 

14. System according to claim 13, wherein the DNS server 
returns the list of IP addresses of second network elements 
together with their names, preferably their canonical names. 

15. System according to any one of the preceding claims, 
wherein, when a second network element is to be subjected to an 
operation blocking its future connection handling capability at 
least temporarily or partly, this second network element is 
excluded from the list a defined time before starting the 
operation . 

16. System according to any one of the preceding claims, 
wherein the first network element is adapted to detect the 
identifier from a message to be sent from a third, connection 
originating or terminating network element to the first or one 
of the second network elements, or to deduce the identifier 
from other information related to the third network element 
such as location information. 

17. System according to any one of the preceding claims, 
wherein the identifier is transmitted as part of a message to 
be sent from a third, connection originating or terminating 
network element to the first network element or to one of 
second network elements. 
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18. System according to any one of the preceding claims, 
wherein one of the second network elements is set as a default 
second network element to be used for handling the connection 
when no other second network element is selected. 

19. System according to .any one of the preceding claims, 
wherein one of the second network elements is set as a master 
second network element to be used for handling the connection 
or transmitting information to another second network element 
when said another second network element is selected for 
handling the connection. 

20. System according to claim 19, wherein the information to be 
transmitted to said another second network element is context 
information . 

21. Method for selecting an address in a communication network 
comprising several network elements, a first network element 
being adapted to select the address of one or more of 
alternatively selectable second network elements, at least one 
of the network elements storing a list of selectable second 
network elements, wherein said list is accessed using an 
identifier identifying an area and/or an identifier identifying 
a desired second network element, said identifier being 
transmitted from another network element or being generated by 
default . 

22. Method according to claim 21, wherein the identifier is a 
Location or Routing Area Identifier (RAI) or target ID, at 
least two second network elements being assigned to the same 
identifier . 
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23. Method according to claims 21 or 22, wherein the identifier 
is a CN identifier. 

24. Method according to claim 21, 22, or 23, wherein 
information on at least two second network elements being 
assigned to the transmitted identifier is sent from the network 
element storing the list to the first network element. 

25. Method according to any one of the preceding claims 21 to 
24, wherein the list of selectable second network elements is 
sent to the first network element in a defined order. 

26. Method according to claim 25, wherein the order is 
depending on the load of the second network elements indicated 
in the list. 

27. Method according to claim 25 or 26, wherein the order is 
depending on the address of the first network element. 

28. Method according to claim 25, 26 or 27, wherein the order 
is depending on the geographical distance between the first and 
the second network elements. 

29. Method according to any one of the preceding claims 21 to 
28, wherein the network is a packet-switched network. 
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30. Method according to any one of the preceding claims 21 to 

29, wherein the second network elements are serving nodes, 
preferably SGSNs. 

31. Method according to any one of the preceding claims 21 to 

30, wherein the at least one network element storing the list 
is a DNS server. 

32. Method according to claim 31, wherein the DNS server 
returns a list of IP addresses of second network elements. 

33. Method according to claim 32, wherein the DNS server 
returns the list of IP addresses of second network elements 
together with their names, preferably their canonical names. 

34. Method according to any one of the preceding claims 21 to 

33, wherein, when a second network element is to be subjected 
to an operation blocking its future connection handling 
capability at least temporarily or partly, this second network 
element is excluded from the list a defined time before 
starting the operation. 

35. Method according to any one of the preceding claims 21 to 

34, wherein the first network element detects the identifier 
from a message to be sent from a third, connection originating 
or terminating network element to the first or one of the 
second network elements, or deduces the identifier from other 
information related to the third network element such as 
location information. 
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36. Method according to any one of the preceding claims 21 to 

35, wherein the identifier is transmitted as part of a message 
to be sent from a third, connection originating or terminating 
network element to the first network element or to one of 
second network elements. 

37. Method according to any one of the preceding claims 21 to 

36, wherein one of the second network elements is set as a 
default second network element to be used for handling the 
connection when no other second network element is selected. 

38. Method according to any one of the preceding claims 21 to 

37, wherein one of the second network elements is set as a 
master second network element to be used for handling the 
connection or transmitting information to another second 
network element when said another second network element is 
selected for handling the connection. 

39. Method according to claim 38, wherein the information to be 
transmitted to said another second network element is context 
information . 

40. User equipment, preferably to be used in a system according 
to any one of claims 1 to 20, or in a method according to any 
of claims 21 to 39, wherein the user equipment is adapted to 
store a Core Network (CN) identifier, in particular the latest 
CN identifier sent by the network, and to insert the CN 
identifier in radio signaling. 
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41. User equipment according to claim 40, wherein the stored CN 
identifier is the latest CN identifier sent by the network. 

42. User equipment according to claim 41, wherein the stored CN 
identifier is a preconf igured CN identifier, which is always 
sent from the user equipment in radio signaling. 

43. User equipment according to claim 42, wherein the 
preconf igured CN identifier is stored on a SIM card of the user 
equipment . 

44. User equipment according to claim 41, 42, or 43, wherein 
the user equipment is a mobile station. 

45. System wherein different Serving nodes assigned to 
different operators are adapted to use the same access network 
for access to a user equipment, the access network being 
adapted to select an appropriate Serving node by using a CN 
identifier . 

46. System according to claim 45, wherein the access network is 
a RAN (Radio Access Network) for radio access to a user 
equipment . 

47. System according to claim 45 or 46, wherein the access 
network is assigned to another operator than the Serving nodes. 

48. Controller, in particular for use in a system as defined in 
any one of claims 1 to 20, or 45 to 47, or in a method 
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according to any one of claims 21 to 44, being adapted to 
select a serving network element for handling a connection, 
either from a list of serving network elements,, or depending on 
an identifier provided by another network element. 

49. Controller according to claim 48, being implemented as a 

i 

Radio Network Controller (RNC) . 

50. Controller according to claim 48, being implemented as a 
Base Station Controller (BSC) . 

51. Network element, in particular for use in a system as 
defined in any one of claims 1 to 20, or 45 to 47, or in a 
method according to any one of claims 21 to 44, containing a 
list of serving network elements. 

52. Network element according to claim 51, being implemented as 
a DNS (Domain Name System), server. 

53. Serving network element, in particular for use in a system 
as defined in any one of claims 1 to 20, or 45 to 47, or in a 
method according to any one of claims 21 to 44, being adapted 
to request connection information such as context information!, 
e.g. PDP context information, from another serving network 
element whem taking over the handling of a connection which is 
or was previously handled by the another serving network 
element . 
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to claim 53, being implemented 
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